home *** CD-ROM | disk | FTP | other *** search
/ Aminet 4 / Aminet 4 - November 1994.iso / aminet / comm / net / spakparnet_0_5.lha / par / steps < prev    next >
Text File  |  1992-11-10  |  4KB  |  125 lines
  1. what do I want?
  2.  
  3. at the moment
  4.   steps for "reading into memory"
  5.   Add DMA address
  6.   send a packet out
  7.   wait for the DMA to complete (from incoming packets)
  8.  
  9.   on the receive side there is a seperate header/body - this is unnec. since
  10.   memory must be allocd for the body anyway - we may as well allocate everything
  11.   in one hit
  12.  
  13.  
  14. for sending:
  15.   can DMA send - this automatically breaks the memory up into however big
  16.   you want
  17.   OR normal send - sends everything out as one large packet
  18.  
  19. problems: aborting on a DMA "read"
  20. solution - have the packet send out results as well
  21.    2 "results" are sufficient since we are mainly interested in amiga dos packets
  22.  
  23. MODIFY:
  24.   ON receiving a packet the entire packet is alloc'd at the begining with a modified
  25.   packet head which changes depending on what should happen with this "packet"
  26.  
  27.   have a combined send, DMA back type affair: Have a standardized DMA return format
  28.  
  29.   NO replymsg's for "servers" since it should be up to them how much they should DMA
  30.   back at a time.
  31.  
  32.  
  33. methods of doing a "write"
  34.   use a "readable" DMA list
  35.  
  36.   send stuff off as a packet and let the destination allocate it and read it in
  37.   one hit - problem - what if we want to write out 20-30K - this chews the network
  38.   for a second - this is not too much of a problem, but it just isn't manners.
  39.   Not a real important problem - we'll deal with this later.
  40.   - however this may be a problem since it is up to the sender rather than the
  41.   receiver to decide on memory use <- this is always the case tho - solution - just
  42.   have the sender break everythign up into chunks however big they want.
  43.  
  44.  
  45. methods of doing a "read"
  46.   use a "recv DMA list"
  47.   send off the combined send DMA reply message
  48.   the parallel port driver will send off the actual message and hold the DMA address for
  49.   later.
  50.   we wait until all DMA has completed, being entirely up to the remote machine
  51.   as to how much it actually writes per packet, then return the message to the caller
  52.  
  53. The remote machine's packet driver must perform the following:
  54.   receive the original message
  55.   begin sending off messages which have no DMA back.
  56.  
  57.  
  58. steps for a "read"
  59. get packet type (short) & length (long) majic (long) chksumhead chksumbody
  60. if type: server (& server exists)
  61.      AllocMem(length)
  62.      Reply(OK)
  63.      GetRemainder (body)
  64.      test chksum
  65.      Reply(OK or BAD)
  66.  
  67. this is the body
  68. if type: dmaintomem (& ok)
  69.      Reply(OK)
  70.      ReadRemainder, write into mem
  71.      if (lengthtogo == 0) read 16 more bytes (the result, 4 longs) into something
  72.      contained in the DMA node
  73.      test chksum
  74.      Reply(OK or BAD)
  75.     return the send-dmaback message if lengthtogo == 0 and everythign is ok.
  76.  
  77.  
  78.  
  79. match to above "read" ("SEND")
  80. send mini-header
  81.   type = new packet (server) or DMABack (write)
  82.   I haave already written this....
  83.  
  84.  
  85.  
  86. is it worth going to this effort to split up our packets?
  87.  I think it is since it makes everything more fluent
  88.  allows more chances for other machines to take the network and not time out
  89.  
  90.  
  91. I have the outline
  92. packet request - possibly split into several parts
  93. - recv'r must put the mem alloc'd into the DMA list for recv'ing
  94. - sender must send it off
  95. - once the recv's mem is full then it sends a message off to the controlling task
  96. - the controlling task then starts sending DMA packets back to the initiator
  97.  
  98. FOR A WRITE
  99. sender sends off "large" packet (which will be split into smaller ones)
  100.   (result place is put into DMA memory)
  101. - actually there must be a request packet and then the rest of the memory
  102. sender waits for DMA mem to fill and then returns the result
  103.  
  104. recv'r simply gets the packet, when the memory has been filled it notifies
  105. the approp task which does stuff, finally DMA-sending the result back
  106.  
  107. - only problem - the sender determines how much memory the recv'r should
  108. allocate - not entirely secure - can be circumvented simply by carrying around
  109. max alloc in the file handles
  110.  
  111. FOR A READ
  112. sender sends "READ packet" to the task & makes the dest a big DMA'able chunk
  113. wait for the DMA to complete
  114.  
  115. the recv'r gets the request and then DMA's back stuff at leisure.
  116. - there must actually be the main body in the DMA list, as well as a result
  117. which is elsewhere - when the result is sent the caller should be notified.
  118.  
  119.  
  120. yes this is a good system
  121.  
  122. -> packet type:
  123. request
  124. DMA write
  125.